The online racing simulator
Searching in All forums
(734 results)
Scawen
Developer
Quote from Degats :One observation, the IS_RES TTime ("session time") doesn't quite match the IS_LAP ETime ("total time")
...
If I understand correctly, the IS_RES time is equivalent to the replay time and IS_LAP is equivalent to the time since the lights go green?

I've noticed that some packets have ETime and others are TTime - are they always consistent with the interpretation of the two times above?

Thanks for the test.

Yes, the IS_RES TTime in practice mode is the time since the start of the session until... and here is the dirty secret... the time the packet is processed at the server (a short and unpredictable time after the packet is sent - in this case 0.47 seconds). And, as you said, the IS_LAP ETime is the time since the lights go green (3 seconds after the start of the session) until the time the car crossed the finish line. So that's how to get the 3.47 seconds difference.

Explanation: The IS_LAP is triggered by an internal packet that has a proper time stamp (from the driver's computer) of total time as that is very important for accuracy. But the internal result packet that triggers the IS_RES packet in qualifying mode doesn't have that accurate time stamp as it was never needed before. So the server goes with the time the packet is processed for this new use of TTime in IS_RES in qualifying. I think for the purposes you are describing, that additional slight delay won't be a problem. I think it could only be a problem if two qualifiers cross the finish line at almost exactly the same time, with exactly the same lap time, then the tie-break between these two identical laps might not get the right order. But that might never happen! Smile And if it did happen I think that would match the order generated by LFS...

EDIT: Sorry, this isn't quite right as they are both triggered by the same internal packet. So I think it would be possible to make the IS_RES TTime in qualifying equal to the associated IS_LAP ETime if needed, by passing some extra parameters to a couple of functions. But then the order might not match the order generated by LFS in that very rare case described.

Quote from vanopaniashvili :Increasing the range of steering wheel rotation is welcome news and I got a question about it. What was the reason behind changing all street cars to 900 degrees of rotation?

I'm concerned about the non-wheel users of LFS. It's certainly gonna affect their understanding of vehicle handling characteristics which they are already familiar with and force them to rethink everything. Obviously, steering ratios play a huge role in letting you know about the handling character of a vehicle and LFS was always familiar with 720 degrees of rotation, which gave a certain steering ratio output while being paired with default 36 degrees of steering lock. It gave street cars a certain driving characteristic, which is also what most of the users are familiar with. Changing LFS's signature steering ratio, might cause a confusion in LFS users.

I always knew the steering wheel turns in LFS were too low, compared with real road cars. I had already changed most of the road cars in the development version to the new value. It is an old request to update the steering angles, maybe ever since the higher range controller wheels were available. So now as I was dealing with wheel turns on the racing cars I started to look into steering ratios.

Side note for anyone who doesn't know: steering ratio is the degrees turned by the steering wheel, compared with the degrees turned by the front wheels. https://en.wikipedia.org/wiki/Steering_ratio

Normally in road cars this is between around 12:1 and 18:1 - usually closer to around 15:1 - but in LFS previous versions:
- FWD road cars had a ratio of 12:1 (720 deg steering wheel for 60 deg road wheel)
- RWD road cars had a ratio of 10:1 (720 deg steering wheel for 72 deg road wheel)

So the previous version of LFS was outside of the values ever seen in real road cars. With the new adjustment, the FWD cars have a ratio of 900:60 which is 15:1 and the RWD have a ratio of 900:72 which is 12.5:1 and this is closer to reality (though still a bit low in the RWD case).

I know this will make the cars feel different, while having the same underlying physics, but I'm hoping that as it's closer to reality that shouldn't be a bad thing.

EDIT: This change should not affect mouse or keyboard users at all. In their case the keyboard or mouse operates the steering directly so there is only a graphical change. The change in feeling should only affect wheel users and maybe has a slight affect on joystick users.

Quote from tankslacno :Hi! I've noticed several strange things and bugs in training lessons. At least one of them is related directly to this test patch and I found two others due to me trying to test that new Live Replay-feature in this test patch, meaning that they could be related to this test patch as well.

Thanks for the detailed descriptions.

Some of them I won't worry about but I will have a look to see if some of them can be corrected easily.
Last edited by Scawen, .
Scawen
Developer
Quote from Degats :Would it be possible to set TTime to the session time when the lap was completed, or is there a technical reason why it can't be?

You should find the TTime in IS_RES now has the qualifying session time. Please let me know if it looks right. I did a quick test with the IS_RES appearing live and when requested with TINY_RES.
Scawen
Developer
Test Patch U24 is now available with updated steering animations and new steering wheel rotation limits. Road cars now have 900 degrees steering wheel turn instead of 720. XF and UF GTR now have 540 degrees instead of 720. The new values are more realistic. This may affect the feeling of the cars if you use a wheel.

Steering:

Road cars now have 900 degrees steering range with default setup
XF and UF GTR have 540 degrees steering range with default setup
Updated and fixed steering animations to cover new steering range
Removed option "Move view with animation" which had little effect
FIX for new bug: Steering wheel could turn too far with some setups
FIX for new bug: Switching setups while driver visible could crash

InSim:

IS_RES: TTime in qualifying now indicates time in session
IS_RES: PLID is now zero if the player has left the race

Misc:

Blocked messages remain blocked when returning from game to lobby
Command /block [0/1/2] : block user messages (like the minus key)

Translations:

More updated translations. Thank you very much, translators.

https://www.lfs.net/forum/thread/95016
Scawen
Developer
Quote from Gutholz :It is not possible to assign "block chat" to a button. It is hardcoded to the minus-key "-" and that key is not supported by the /press function.

In the current test patch, you can use the command /press minus (or /shift minus)

In the version I should release this afternoon, there is also a new text command /block X
/block [0/1/2] - block messages (none / user / all)
Scawen
Developer
OK, the test patch won't be today. I've updated all the steering animations and set all the road cars to have 900 degrees of steering wheel rotation with the default steering lock. There are a few more things to do, so hopefully a test patch tomorrow.
Scawen
Developer
Quote from martin18 :Scawen is there anything we can do about steering lock and steering degrees? When set to 45 degrees max steer lock steering turns now to 900. Now when set to anything past that the vehicle steering wheel can not be matched to racing wheel.

Yes, I have noticed that bug. If you increase the maximum lock, at the point you reach "Car's steering wheel turns 1080 degrees" then everything is OK. The bug comes when you continue to increase the steering lock past that point, the screen display still says 1080 degrees but the in-game wheel turns further. I've fixed that in my version and I'm also updating the steering animations to keep going up to the new limits.

I plan to release another patch that is compatible with the current test patch, hopefully on Wednesday. Nothing very exciting in it but a few fixes.
Scawen
Developer
It is CPU, not GPU, time which is being measured. Actually it's just time itself between one point and another.

The "Draw" section is supposed to represent the time taken for the CPU to work out everything related to drawing the shadows, environment maps, mirrors, main views, etc. During this time there are a lot of calculations and thousands of calls to D3D to set constants, set active textures, set vertex and index buffers, and request sections of those buffers to be drawn. Even some vertices and triangles to be sent to the GPU every frame (for flexible objects like drivers and tyres). There is a *lot* of work for the CPU to do when drawing.

That is why it can help to separate physics and rendering onto separate threads. The GPU doesn't just magically know what do to, it is instructed by thousands of calls every frame, from the CPU, through Direct3D. If the CPU didn't have to do much then there would be no need for a separate thread for rendering.

However, there is something seemingly anomalous about a high value in "Draw" in certain situations. In my case I can make Draw go over 90% by selecting exclusive mode full screen (SHIFT+F10) with Vertical Sync enabled. I don't know exactly why that is without looking into it, but it seems quite certain that the time while we are waiting for the vertical sync, is within the start and end of the section I have marked as "Draw". It's nothing to worry about.

If I go full screen in borderless window mode (SHIFT+F11) then the waiting time is in "Flip" which I would have expected to be the case in exclusive mode full screen too. So that's the only anomaly but I'm not really too worried about it.

Without vertical sync enabled, but frame rate limited, the spare time moves into "Sleep" so we get a much better reading for how long the Draw is taking. If you disable frame rate limitation then frame rate goes insane and Draw goes up to a high number. That is expected as we are asking LFS to draw as many frames as possible with every scrap of time remaining.

That is only a waste of energy. Frame rate should either be limited to a set value or vertical sync should be used. There is no point in extremely high frame rates, specially since the new test patches have sorted out a controller issue that previously caused high frame rates to be useful for force feedback.

I repeat - that is no longer the case. Please save some energy and heat by limiting frame rate (e.g. 100 fps) or using vertical sync if you prefer.
Last edited by Scawen, .
Scawen
Developer
All the vehicles with front wheel drive (including four wheel drive) have less steering lock because of the CV joint in the front drive system. Of course in LFS the CV joint doesn't really exist but we don't want to allow impossible things.

I have not researched recently into the lock limitation of CV joints. I do know that ordinary road cars with front wheel drive have a quite bad turning circle compared with RWD cars. If that was an easy problem to solve then manufacturers would do it.

Of course it would be wrong to allow extreme steering angles for vehicles with front wheel drive. There may be some cars where it is reasonable to increase the lock a bit more but I don't have any appetite for looking into that type of thing now.

As I've said a lot of times, I want to get back to the development version. It's really important to me. I hope we don't have to do any more incompatible test patches in this series. My brain already feels quite mashed with all these recent updates which were not planned. I don't regret them - I think there are so many new possibilities. But we have come to the end.

Of course, we are still in testing and I do want to know if anyone finds any issues.
Scawen
Developer
Now that you can adjust your tyre width, we don't need to consider balancing the GTR class. Instead, the community and race organisers can work out what works well and specify limits for events.

Thank you for the feedback. I think it's good that we came round to a flexible system that allows so many possibilities for drifting, rallycross and hard track racing. And without messing up any existing categories or needing to reset any hotlap tables.

I'll close this thread now. Please try out the new version and leave comments on the test patch thread.
https://www.lfs.net/forum/thread/95016
Scawen
Developer
Quote from Flotch :...regarding the hotlap tables, if the new tires for some of the cars are 5mm thinner, I suppose the times done previously by the faster guys won't be reached in this new version (if that matters).

I suppose it does matter a bit. I was thinking maybe the XR GT and FZ GTR rear tyres are wider than they need to be and might even be faster with a thinner tyre due to lower wight and rolling resistance. But that might require a lot of testing that could be a waste of time.

Quote from Nadeo4441 :What about the h-shift pattern in XRR then?

Good point, didn't think of that.

Quote from Pathseeker :i suggest just stick with changes for those 3 GTR cars tyre change option, nothing else.

This might be the best idea, yes. But I remember race organisers use restricted UFR and XFR so maybe they would like some narrow tyres as a different type of restriction?

Quote from aanrus :Will maybe leave it for later? When will be released the new physics, and when all the results will be deleted.

That might be the best idea, yes.

One thing I am trying to do here is escape from the trouble of balancing these new categories for racing and also for drifting. If the users can adjust tyre size then there is no problem.

If we keep the configurations then it could be that the tyre size adjustment is only applied to the new configurations. So they can be balanced for racing and drifting by users after the release. But if the code is there (and I already coded a test version of tyre width reduction) then it could easily be applied to other cars too.

Thanks for the replies, I'm just trying to think this through with you.
Scawen
Developer
I am struggling to understand this. It gets to "CreateDevice" and then that's the last we see. It doesn't report that CreateDevice failed or move onto the next step. So it seems to hang in CreateDevice. But that is a Direct3D function, and your version U does it fine. Also you reported that U13 was working fine until you got a Windows update.

A couple of questions:

1) Originally you said you needed to do a hard reset. But if you start in a window, then when LFS hangs, can you use the Windows Task Manager to end the LFS process? So you don't need to restart the computer?

2) If you can start the Task Manager when LFS hangs, can you see the CPU usage of the LFS process during the hang?

In case you would like to do another test, I've collected together the LFS.exe from test patches U2 to U12 (excludes U8) into a zip file. Maybe you could try and see if any of them work. I suggest you start with U2. If it works then try U3... go through until you find the one that doesn't work. It's possible that could narrow down the changes between one version and the next that causes the problem (if it really is a problem in LFS).

http://www.lfs.net/file_lfs.php?name=LFS_EXE_6U_2_12.zip
Scawen
Developer
Another Incompatible Test Patch, U22:

I hope the extra 10mm tyre width (front and rear) on the XRR make it better for drifting and a better match for the FZR in hard track racing.

Changes from 0.6U21 to 0.6U22: NEW INCOMPATIBLE VERSION

New configurations are now called ALTERNATE (not DRIFT / RX)
Small change to XR GTR alternate config - 10mm wider tyres
Virtual steering gauge hidden if live settings or pit instructions
New fuel options can be filtered and are visible on selected host
InSim IS_SPX and IS_LAP new byte Fuel200 indicates fuel remaining
FIX: Auto clutch time was wrong in the XR GTR in alternate config

https://www.lfs.net/forum/thread/95016
Scawen
Developer
Quote from Degats :Tested and working fine Thumbs up

Would it be an idea for the "refuelling allowed" rule to be shown on the server rules when clicking on a server in the server list? (along with pitstop required etc)

Thanks for the test and yes I should include the rules on that page.

Quote from R0ut66 :Why change the whole system sensitivity just to make the car more driveable? For me makes no sense. LFS should have an mouse sensitivity option

As kagurazakayukari says, LFS uses the mouse movement all the way from the left side of your screen to the right side of the screen to move your car steering from the left to right extreme. So it's already as 'insensitive' as it can possibly be. Are you using full native desktop resolution for LFS? I can only think of slowing down the mouse movement in Windows (but I think you said it is already as slow as possible) and what about making sure mouse acceleration is switched off?

Quote from Extreme1234 :How will maxing out ff steps and ff rate efect my G29? Would it make it feel more detailed? Can you explain what those values represent in ffb?

400 steps means that the steps of force go up in steps of 25 'units' where 0 is no force and 10000 is maximum force. I think the default of 400 steps and 50 Hz is enough on a G27. I don't know about a G29. To feel the effect you could reduce the number of steps to a low number then try driving a car in a slow slalom from left to right. You should notice the 'notches' as the force increases. So then you can increase the number of steps to the point where you can't feel the notches.

The reason for limiting the steps is to avoid constantly streaming new forces to the wheel, when the force hasn't changed enough to notice. This seemed to be a problem on older computers when this could reduce responsiveness by overloading the operating system with new force requests. I don't really know how much of a problem it is these days to send excessive force changes. The high numbers are really for direct drive wheels where the tiniest changes become noticeable.
Scawen
Developer
Thanks for the test. I hope this can solve the problem for B0mberMan.

But I would really like to know if this is a bug in the Pimax system (so Pimax developers should fix it) or if LFS is doing something wrong or could somehow detect and avoid FFR.
Scawen
Developer
Quote from meuhmeuh :So I retried and I' have a deb.log file (I don't understand):

It looks as if it started up, then 9 second later started to shut down.

Feb 03 20:26:23 init sound
[9 seconds elapsed]
Feb 03 20:26:32 shutting down

Please could you try again, using U21 test patch? There is a bit more logging.

Also if you could disable anti-virus and see if that works, that would be helpful.

Thanks!
Scawen
Developer
Test Patch U21:

Interface:

Brakes / TC tab in garage separated into two columns (e.g. FZ50)
FIX: Heat in garage car's tyres was not updated when tyre changed

New handling for 'CAR.lfs' and 'shift_type.lfs' scripts:

LFS runs 'road.lfs' / 'sequential.lfs' / 'paddle.lfs' directly
(previously these scripts were called from a CAR.lfs script)
This is done after loading a car and immediately before CAR.lfs
Commands to run these scripts from another script are ignored

Graphics:

Avoid upward lighting related to ground colour in internal views

InSim:

New bytes output if /showfuel=yes
IS_NPL Fuel : initial fuel load
IS_PIT FuelAdd : fuel added

Translation update for help.txt:

host_cars - max is now 32
guest_cars - max is now 32
max_packs - max is now 12
mip_bias - default settings now -0.5 / -1.0 / -1.5 / -2.0

https://www.lfs.net/forum/thread/95016
Scawen
Developer
Thank you all for the testing and feedback.

Quote from tumes925semut :Need make that page thin.

Thanks, I'll change the Brakes / TC tab to two columns.

Quote from Flame CZE :With the H-pattern gearbox for the RX version of XRR, the single XRR.lfs script for that car is no longer applicable for both configs. The gearbox settings have to be changed manually when switching between the configs.

I haven't checked this out yet but how about if the scripts sequential.lfs, road.lfs and paddle.lfs were run directly (not from another script) depending on the actual shift type after the car is loaded? And these specially named scripts would need to be excluded from being run by a /run command so they don't get run from the existing CAR.lfs scripts?

Quote from ELDemon :Hi scawen, clutch issues on fzr also Smile

I did a quick test with the FZR and didn't see clutch issues.
Can you describe exactly how to reproduce an issue?

Quote from THE WIZARD DK :my test went off to a great start in garage (FXR) which inside the garage had totally flat tires. they literally sweep the floor. this was with a normal lfsw setup, normal config as i havent changed anything yet. just logged in and went into garage. and there they were simply totally flat.

I'd like to know how to reproduce this. Can you make it happen again? If so please describe exactly how, and attach the setup if this happens with a specific setup.
Last edited by Scawen, .
Scawen
Developer
Thanks. I've got your version into my test patch folder.

I've changed my version to pps 12.

The two lines you marked bold, I've changed to a single line:

More online DB access commands: https://en.lfsmanual.net/wiki/Keys
Scawen
Developer
Thanks, I've started a test server 'S2 GTR' you are welcome to use. It allows GTR cars and you can select the track.
Scawen
Developer
Quote from tankslacno :Scawen, is it confirmed that in the official version, it'll be possible to add up to 32 AI's per player on multiplayer and that maximum number of packets sent per second by each car will be 12 instead of 6?

I think that is true but I can't remember many test results about the 32 (ai + real) car per connection. It's possible it could change if testing reveals it to be a bad idea. But if it's all working well then there shouldn't be a problem. I think 12 pps is here to stay and don't really want to get back into that stuff now.

I believe online prediction and smoothness is improved a lot, mainly by:

- sending more position packets when needed
- sending tyre deflection in the position packet
- more accurate and frequent temperature & wear updates
- better initialisation of steering after each position packet
New GTR configurations in U19 balancing for hard track racing
Scawen
Developer
Hello racers,

In the new incompatible test patch U19 I've tried to improve the balance between the FZR, FXR and XRR with the new configuration selected. Although the new configs were designed with drift and rallycross in mind, it also creates a new hard track racing category, like the existing GTR class but with a bit less grip due to the narrower tyres. XR GTR also has an H-pattern shifter in the new configuration.

I've tried to keep the cars balanced, in terms of their own handling and hopefully between cars too. It's not possible within a few days to get a race category perfectly balanced, because setups evolve over time. Race directors can adjust performance using ballast. But I'd be interested to know how they compare.

I'm trying to get this tested and finalised as soon as possible so I can get back to the development version.

https://www.lfs.net/forum/thread/95016
Scawen
Developer
Quote from Degats :For some reason, I'm only ever seeing Config == 0 in NPL

Thanks. I had only entered it in the 'request join' version of IS_NPL.
It's now fixed and I've uploaded U18 DCon with the fix.

Quote from Pasci :Hm... I tried yesterday evening the U18 version. I noticed that the hostname input for the target host no longer works. I needed to enter an ip address again. Is the new code accidentally not in this version? That worked great before (incl. U15; i didn't have time to test u16).

I don't know why that would be. In a quick test here it did work. I only tested on my local computer, joining a local server on the same computer. I was able to enter "localhost" or my network computer name and it did join.

EDIT: Was there any kind of message, in the chat or a dialog, when you click GO?
Last edited by Scawen, .
Test Patch U25: Multiplayer Updates
Scawen
Developer
WARNING: THIS IS A TEST

THIS DOES NOT CONTAIN NEW TYRE PHYSICS OR THE NEW GRAPHICS SYSTEM

PLEASE TEST BEFORE YOU POST


THIS PATCH IS NOT COMPATIBLE WITH VERSION U


Hello Racers,

Here is a new test patch: 0.6U25

The changes are listed below.

0.6U25 is NOT COMPATIBLE with 0.6U

- You can NOT connect online with 0.6U
- You CAN play replays from 0.6U

Please back up or rename your LFS.exe from version U so you can revert to it if necessary.


Changes from 0.6U23 to 0.6U25: COMPATIBLE WITH U23

Steering:

Road cars now have 900 degrees steering range with default setup
XF and UF GTR have 540 degrees steering range with default setup
Updated and fixed steering animations to cover new steering range
Removed option "Move view with animation" which had little effect
FIX for new bug: Steering wheel could turn too far with some setups
FIX for new bug: Switching setups while driver visible could crash

Training:

FIX: AI changed to low fuel load if overtaking lesson restarted
FIX: AI skill / admin commands no longer processed during training
FIX: Training lesson did not end if replay saving was interrupted
FIX: Refuelling depended on refuelling allowed in single player
FIX: Logo was visible under title during lesson replay

Misc:

Removed debug message "Replay name : temp_mpr"
Saving replay name now shown beside option in Options - Game
Blocked messages remain blocked when returning from game to lobby
Command /block [0/1/2] : block user messages (like the minus key)

InSim:

IS_RES: TTime in qualifying now indicates time in session
IS_RES: PLID is now zero if the player has left the race

OutSim:

OutSim packet is documented in docs\OutSimPack.txt
Added steering torque as additional field in new OutSim
All data options can be switched on with OutSim Opts 1ff

Translations:

More updated translations. Thank you very much, translators.


Changes from 0.6U16 to 0.6U23: NEW INCOMPATIBLE VERSION

Multiplayer prediction:

Position packet now includes contact patch offset for each tyre
Wear and temperature packet is more frequent and more accurate

Pit stops:

Command /canrefuel (no/yes) to set refuelling allowed in pit stops
Damage repair not required when changing tyre pressure or compound

New ALTERNATE setup configuration for the five GTR cars:

Selecting the new config in XRR/FZR/FXR decreases tyre width a bit
With alternate config, narrower tyres may be selected (adds offset)
Also ROAD_SUPER, ROAD_NORMAL, HYBRID, KNOBBLY tyres may be selected
High "Maximum Lock" is possible in XRR/FZR with narrower wheels
XR GTR in ALTERNATE config has H-pattern shifter

Tyre choices and steering lock:

XFR and UFR maximum steering lock increased to 30 degrees
LX4 and LX6 maximum steering lock increased to 45 degrees
Single seater racing cars can now use ROAD_SUPER tyres
Steering wheel turn amount changes with maximum lock

New handling for 'CAR.lfs' and 'shift_type.lfs' scripts:

LFS runs 'road.lfs' / 'sequential.lfs' / 'paddle.lfs' directly
(previously these scripts were called from a CAR.lfs script)
This is done after loading a car and immediately before CAR.lfs
Commands to run these scripts from another script are ignored

Controls:

Handbrake strength is now separately adjustable

Graphics:

Avoid upward lighting related to ground colour in internal views

InSim:

Config byte added to IS_NPL packet indicates setup configuration
IS_CPP Pos is now relative to "Centre view" not the user setting
IS_NPL RWAdj / FWAdj indicate rear / front tyre width reduction
New bytes set if /showfuel=yes: IS_NPL Fuel / IS_PIT FuelAdd
IS_SPX and IS_LAP new byte Fuel200 indicates fuel remaining

Interface:

Tyre size displayed in Tyres tab in Garage
Brakes / TC tab in garage separated into two columns (e.g. FZ50)
FIX: Heat in garage car's tyres was not updated when tyre changed
Virtual steering gauge hidden if live settings or pit instructions
New fuel options can be filtered and are visible on selected host
When alternative config is selected F12 display shows tyre size
/press and /shift commands now support 'minus' as parameter
minus key (block messages) now works in free view mode

Misc:

Maximum number of layout objects increased to 2400
You can now add up to 32 local drivers (real + ai) in multiplayer
Restored code preventing 2 cars joining autocross within 3 seconds
FIX: Wrong warning "Road tyres on rallycross track" in hotlapping

Translation update for help.txt:

host_cars - max is now 32
guest_cars - max is now 32
max_packs - max is now 12
mip_bias - default settings now -0.5 / -1.0 / -1.5 / -2.0

Translations:

Many updated translations. Thank you, translators.


Changes from 0.6U to 0.6U16: FINAL VERSION COMPATIBLE WITH 0.6U

Interface:

Pit speed limit is shown when car speed is below 2/3 of limit
Yellow and blue flags now alternate with RCM or penalty message
Prevented auto-repeat on block message and light switching keys
Command /spectv no - prevent selecting TV camera on spectate
Momentary flick to rear view after SHIFT+R is now avoided
Avoided downshift after pressing SHIFT+X to exit free view
In fact any 'key held' function after SHIFT+key is prevented

F12 pit instructions:

Pressure change with new tyre no longer counts as SETUP CHANGES
A new 'cancel' option beside the 'setup changes requested' line
Settings that will be adjusted are now shown in light red colour
FIX: rear tyre pressure was limited by front tyre pressure limits
FIX: symmetric pressure/camber request remained after pit stop

Multiplayer:

Maximum packets per second (/pps) has been increased to 12
Rolling resistance included in catch-up phase of prediction
Reduced steering glitch each time a position packet is received
Position packets are sent more frequently in response to steering
Command /showfuel (no/yes) allows remote car fuel load to be seen
More accurate transmission of fuel load from local to remote car
Most admin commands with parameter omitted report current value
Easier to set up LAN race: local IP address is shown on host screen
You can enter the local network computer name instead of IP address
FIX: Remote cars with worn tread could wrongly get a puncture
FIX: Car on pit speed limiter sent maximum packets per second
FIX: Stop-go penalty caused car to get stuck in custom pit stop
FIX: Remote car's tyre temperature over 200 appeared black (cold)
FIX: Remote tyre temperatures increased too slowly in skid or spin

InSim:

IS_CPP FOV can now be used in-car but not smoothed (0 = no change)
InSim NLP / MCI minimum time interval reduced to 10 ms (was 40 ms)
FIX: It was possible to miss IS_PSF packet after taking over car
FIX: STime in IS_PSF packet was wrong after car was taken over
FIX: Free view roll is now reported in InSim IS_CPP packet

CPU usage display:

In Graphics or Misc options (in-game) click car icon then 'P'
You can now see CPU usage for Physics, Draw, Prediction, etc.
The "Pred" line shows CPU usage for prediction of remote cars
Prediction time also shows up in an MPR if /mprlag is set

Support for live multiplayer replays:

Replay identified as live when starting to watch an unfinished MPR
Does not exit replay after fast forwarding to current time
Catch up to live position by clicking >| button
Skins can be downloaded while watching a live replay
Save replay while temp_mpr is being viewed - copy instead of rename
Start new mpr while temp_mpr is in use - tries temp_mpr_1 (up to 9)
/mprflush X to flush mpr to file every X seconds (0 = disable)
MPR / SPR are prevented from being named temp_mpr / temp_spr

VR:

Updated OpenVR to version 1.10.30
Improved timing of obtaining view each frame
New "Antialiasing" option to select 4x or 8x multisampling
New "Resolution adjustment" slider (also known as supersampling)
Names over cars could fade differently in each eye in Pimax headset
Virtual keyboard is shown at dialog height if no dialog is visible
Space bar VR click auto disabled when you type with real keyboard
FIX: Head tracking / mirrors wrong if car leaned with horizon lock
FIX: Free view FOV was wrong after entering VR in free view
FIX: Names above cars looked wrong in Pimax headsets
FIX: Some trees looked wrong in Pimax headsets

Skin downloads:

Faster skin downloads when joining server (and auto updater)
Slightly faster skin downloads when driver joins race in-game
FIX: Skin downloading could get stuck after a large header

MPR debug commands:

/mprlag X simulates online packet delay of X ms (+ no smoothing)
/mprsmooth X (0 or 1) to disable or enable input smoothing

Views:

Horizon lock now has a strength slider option
View filter time maximum value increased to 1 second
Improved key control (4/5/6/7) of free view field of view
Three screens are now assumed when aspect ratio is 4:1 (was 3:1)
Free view mode minimum field of view reduced from 10 to 2 degrees
FIX: Filtered view went wrong with low filter time + replay speedup

Graphics:

Car shadows now use anisotropic filtering to reduce shimmering
Increased distance for car subobjects to become invisible

Controls:

Gearshift debounce setting now applies to all controller buttons
Mouse X and Y sensitivity (in Axes tab) lower limit reduced to 0.5
FIX: Rare manual shift at high speed to 1st/rev during auto shift

Force Feedback:

New settings are available under Axes / FF in Options - Controls
FF Steps maximum value is now 10000 (the maximum in DirectInput)
FF Rate is now controlled by a user setting (25 / 50 / 100 Hz)

More telemetry data for OutSim:

Enable by setting the OutSim Opts value in cfg.txt
All data options can be switched on with the value ff
The new data is documented in a header file OutSimPack.h

Misc:

When LFS is set to close the reason is logged to deb.log file
Added a little more logging about D3D initialisation to deb.log
CAR.lfs scripts are reliably run when user car is spawned or reset
FIX: Memory leak related to threads (most often for skin download)
FIX: Replays from old Westhill before 2015 now marked as obsolete
FIX: Driver names ending with a lead byte could corrupt text
FIX: Issues with driver names ending with caret character


INSTALLATION:

A FULL version of LFS 0.6U must already be installed


To install the PATCH using the SELF EXTRACTING ARCHIVE:

1) Move or save the patch into your main LFS folder
2) Double click the patch to extract it to that folder
3) When you see "Confirm File Replace" select "Yes to All"
4) Now you can start LFS in the normal way

NOTE: You can see if the patch is correctly installed when you run
the program (LFS.exe). At the bottom of the entry screen: 0.6U25


DOWNLOADS:

IF YOU ALREADY HAVE 0.6U:
PATCH 0.6U TO 0.6U25 (SELF EXTRACTING ARCHIVE)
www.lfs.net/file_lfs.php?name=LFS_PATCH_6U_TO_6U25.exe (1.8 MB)

FOR HOSTING ONLY:
DEDICATED HOST 0.6U25 (non-graphical version for hosting only):
www.lfs.net/file_lfs.php?name=LFS_S3_DCON_6U25.zip (1.8 MB)
Last edited by Scawen, .
Scawen
Developer
In test patch U16 there are a few more messages logged about D3D initialisation. So we might get more of an idea how far it gets before the hang.

https://www.lfs.net/forum/thread/93185
Scawen
Developer
Test Patch U16. I'm expecting this to be the last compatible patch before the incompatible test.

Interface:

Key control (4/5/6/7) of free view FOV improved and reaches 2 deg
Prevented auto-repeat on block message and light switching keys

InSim:

IS_CPP FOV can now be used in-car but not smoothed (0 = no change)
IS_CPP Pos is now relative to "Centre view" not the user setting
FIX: It was possible to miss IS_PSF packet after taking over car
FIX: STime in IS_PSF packet was wrong after car was taken over
NOTE: for these fixes the new driver taking over must have U16

Misc:

Added a little more logging about D3D initialisation to deb.log

https://www.lfs.net/forum/thread/93185
FGED GREDG RDFGDR GSFDG